NPS52-85-006 



FedDocs 
D 208.14/2 



NAVAL 



POSTGRADOATE SCHOOL 

Monterey, California 




EXPERIENCE WITH Q: 
IMPLEMENTATION OF A 
PROTOTYPE PROGRAMMING ENVIRONMENT 
PART I 



Bruce J. MacLennan 



May 1985 



Approved for public release, distribution unlimited 



Prepared for: 

Chief of Naval Research 
lington, VA 22217 



NAVAL POSTGRADUATE SCHOOL 
Monterey, California 



^ / Lr ' 

, g^- ~ OD^ 

O. 



Rear Admiral K.H. Shumaker 0 . A. Schrady 

Superintendent Provost 



The v/ork reported herein was supported by Contract N00014-85-WR-24057 
from the Office of Naval Research. 

Reproduction of all or part of this report is authorized. 

This report was prepared by: 



UNCLASSIFIED 

SECURITY CLASSIFICATION OF THIS PAGE fV*Ti«n Dalx Enlarad) 



REPORT DOCUMENTATION PAGE 



READ INSTRUCTIONS 



1. REPORT NUMBER 

NPS52-85-006 


2. GOVT accession NO. 


3. RECIPIENT’S catalog NUMBER 


4 TITLE (and Subtitte) 

■EXPERIENCE WITH IMPLEMENTATION OF A PROTOTYPE 

PROGRAMf-lING ENVIRONMENT - PART I 


S. TYPE OF REPORT & PERIOD COVERED ^ 

C 

< 

< 


6. PERFORMING ORG. REPORT NUMBER < 

< 


7. author^s; 

Bruce J. MacLennan 


8. CONTRACT OR GRANT NUMBER^f; 


9. PERFORMING ORGANIZATION NAME AND ADDRESS 

Naval Postgraduate School 
Monterey, California 93943 


10. PROGRAM ELEMEN T. PROJECT, TASK 
AREA 4 WORK UNIT NUMBERS 

61153H; PRO 14=0 8-01 
N000l485m?4057 


H CONTROLLING OFFICE NAME AND ADDRESS 

Office of Naval Research 
Arlington, Virginia 22217 


12. report date 
May 1985 


13. NUMBER 0 F PAGES 


U. monitoring AGENCY NAME 4 ADDRESSr// dUlerent (rom ControUlng Offlca) 

1 

1 


15. SECURITY CLASS, (of this report) 

unclassified 

1 


i 15« DECLASSIFICATION/ downgrading 
1 SCHEDULE 


16 DISTRIBUTION ST A T E M EN T ^ s 


17. distribution statement (of the abstract entered In Block 20, If different from Report) 

Approved for public release, distribution uhlimited 


18 SUPPL EmEN TARY NOTES 


19. KEY WORDS (Continue on reverse aide If necessary and Identify by block number) 

Object-oriented programming, production rules, production systems, entity- 
relationship, pseudo-natural language, knowledge representation, natural 
language interface, logic programming, simulation language, rule-based system, 
knowledge base, programming environment, software prototyping, rapid 
prototyping, syntax-directed editor, unparser 


20. abstract (Continue on reverse side if necessary and Identify by block number) 

This is the first report of a series exploring the use of the 0 , programming 
notation to prototype a programming environment. This environment includes 
an interpreter, unparser, syntax directed editor, command interpreter, debugger 
and code generator, and supports programming in a small applicative language. 

The present report describes the interpreter, unparser, syntax directed editor, 
command interpreter and debugger for a subset of the language, namely arithmetic 
expressions . 



4P 

sS 



D ® 

, m < 

: w 

O ' 

o 



nn 

I JAN 73 



1473 EOITION OF 1 NOV 65 IS OBSOLETE 
5 N 0162' LF. 0N' 660I 



UNCLASSIFIED 



security CLASSIFICATION OF THIS PAGE (Whmn Bntmrmd) 



EXPERIENCE WITH Q 



IMPLEMENTATION OF A 
PROTOTYPE PROGRAMMING ENVIRONMENT 

PAR T I 



Bruce J. MacLennan 
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Abstract: 

This is the first report of a series exploring the use of the H programming notation to prototype a pro- 
gramming environment. This environment includes an interpreter, unparser, syntax directed editor, 
command interpreter, debugger and code generator, and supports programming in a small applicative 
language. The present report describes the interpreter, unparser, syntax directed editor, command 
interpreter and debugger for a subset of the language, namely arithmetic expressions. 



1. Introduction 

Our goal is to explore in the context of a very simple language the use of the H programming notation 
jMacLennan83, MacLennanSS] to implement some of the tools that constitute a programming environ- 
ment. Succeeding reports will extend the tools described in this report*. 

The structure of this report is as follows: First we briefly review the Q programming notation for 
describing transformations on relations. Second, we define a simple language --- the language of arith- 
metic expressions. An abstract syntax for this language is defined in terms of relations. Third, we dis- 
cuss abstract interpretation of programs in this language. Fourth, we modify the interpreter to accom- 
plish unparsing. Next, we look at error recovery and interactive debugging. Finally, we consider syntax 
directed editing of abstract programs. 



* Support for this research was provided by the Office of Naval Research under contract N00014-85- WR-24057. 



- 1 - 



2. OVERVffiWOFH 



2.1 Requirements for a Programming Environment Database 

To understand the relevance of 0 to programming environments we begin by stating the requirements 
for a software development database. It wdll be required to store and interrelate many kinds of infor- 
m atio n : 

— Programs 

— Specihcations 

— Documentation 

— Version Information 

— Comments 

— Object Code 

— Implementation Hints 

— Test Data 

— Test Results 

— Reports 

— Runtime Structures 

In prototyping tools and environments, we want to make a minimum of implementation commitments. 
Hence, it is convenient to take a relational view. This is because relations are a well-understood, 
implementation-independent way of viewing databases. 

2.2 RELATIONS 

VVe will view the computer system (or network) as containing a (possibly large) number of (finite) rela- 
tions. The number of relations is not fixed; new (empty) relations can be created by direct (user) or 
indirect (program) request. The tuples in relations can contain: 
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Values: For example, numbers, Booleans, characters, strings, “pure’' lists. 



• Objects: Essentially unique IDs; their only properties are the relations in which they participate. 
Relations are themselves objects. 

2,3 Notation 

We use the notation ‘ ( i , y, . . . , 2 ) ’ to mean the tuple [x ,y , . . . , z) is in R. Similarly, 

( X , y, . . . ^ 2 ) ’ means that there is no such tuple in R . 

Operations on the database are described by a kind of production rule: 

cause => effect 

The effect part is composed of a series of transactions. There are two forms for a transaction: 

• R {x ,y , . . . , z) means add the tuple ( x , y, . . . ^ 2 ) to . 

• -^R{x,y, . . . ; 2 ) means delete the tuple from R, 

The arguments x, y, . . . , 2 can be any applicative expressions. They can also be procedures^ i.e., 
parameterized database transformations. 

The cause part has the form: 

condition , • * • 

The cause is a sequence of conditions separated by commas. Each condition asks whether certain rela- 
tions hold certain tuples. 

The condition ‘i?(x,y, . . . , 2 )’ succeeds if there is a tuple (x ,y, . . . ^ 2 ) in R . On the other hand, 
... ^ 2 )’ fails if there is such a tuple in R. The arguments x, y, ... j z have the forms: 

• a constant matches itself; 

• a free variable matches anything, and becomes bound to value it matches. 

• aji applicative expression matches its value. 

We consider several examples of conditions. 7? (2, 3) succeeds if the pair (2,3) is in R. -^i?(2,3) 
succeeds if the pair (2,3) isn^t in R. If ‘y’ is free (unbound), then R (2,y) succeeds if there is a pair of 
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the form (2.t;) in R\ variable ‘y’ becomes bound to i; . -/?(2,y) succeeds if there is no pair of the 

form (2,t/) in R. If ‘y' is bound to f, then 5(y,3) succeeds if the pair (t’,3) is in 5. -’5(y,3) 

succeeds if the pair (r,3) is in 5. 

An implicit join is a rule in which the same free v'ariable appears in several conditions. For exam- 
ple, 



^(2,y), 5(y,3) 



succeeds if; 



1. There is a pair of the form (2,t;) in R 

2. The pair (t;,3) is in 5 

It fails, otherwise. Note: There may be many pairs of the form (2,t;) in R. The join succeeds if for 
one or more of them (v,3) is in S. Any conjunction of conditions is allowed in the cause. 

2.4 Stack Example 

To illustrate these ideas we show the Q definition of a stack manager. First we introduce the relations 
and their intuitive meanings: 

• Stack(«) — object s is a stack 

• Con tents( z ) — the list z is the contents of s 

• Push(a,z,«) — a pushes z on « 

• Pop(a,fi) — a pops « 

• Receives( a ,z ) — a receives z 

The domains of these relations are described by the following assertions (second order relations) . Thus 
‘Degree (Contents, 2)’ means that all the tuples in Contents have two elements; ‘Domain (list, 1, Con- 
tents)’ means that the first elements of the tuples in Contents satisfy the ‘list’ predicate; and ‘Indexed 
(Contents, 2)’ means that the second elements of the tuples in Contents are all unique. Each assertion 
is shown in two notations: the usual predicate notation and a pseudonatural notation (Q supjx)rts 

several semantically equivalent notations; see (MacLennan84. Ufford85]). 
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• Degree (Stack, 1) 

‘Stack^ has degree 1. 

• Degree (Contents, 2), 

‘Contents^ has degree 2. 

• Domain (list, 1, Contents) 

‘list’ is domain 1 of ‘Contents’. 

• Domain (Stack, 2, Contents) 

‘Stack’ is domain 2 of ‘Contents’. 

• Indexed (Contents, 2) 

‘Contents’ is indexed by domain 2. 

• Degree (Push, 3) 

‘Push’ has degree 3. 

• Domain (Stack, 3, Push) 

‘Stack’ is domain 3 of ‘Push’. 

• Degree (Pop, 2) 

‘Pop’ has degree 2. 

• Domain (Stack, 2, Pop) 

‘Stack’ is domain 2 of ‘Pop’. 

• Degree (Receives, 2) 

‘Receives’ has degree 2. 

The pop rule describes how to pop a stack: 
Stack (fi). Pop (a,^), Contents (i,fi) 

-iPop (a,*), 

-^Contents ( i , « ) , 

Receive (a, first [x]). 



Contents (rest [xj. «) 

It can be read as follows: “If « is a stack, a is popping s, and x is the contents of s, then a is not pop- 
ping 6, X is not the contents of 6, a receives the first element of z, and the rest of x is the contents of 

The push rule is analogous: 

Stack («), Fhish Contents (y,«) 

--Push ( a ,x ,5 ) , 

-^Contents ( y,«) , 

Receive (a,^), 

Contents (cons [x,y], «) 

If 5 is a stack, a is pushing x on and y is the contents of s, then a is not pushing x on y is not 
the contents of a receives and the result of consing x on y is the contents of s. 

2.5 PHirther Notational Conventions 

Notice that in the push and pop rules, conditions found to hold in the cause parts of rules are often 
canceled in the effect parts. Since this is a very common situation we introduce the following cancella- 
tion convention: When a tuple found in the condition is removed by the effect, i.e., a relation that holds 
in the condition is canceled by the effect, we can indicate this by an before the condition. For 
example, the pop and push rules can be written: 

Stack(«), ^Pop(a,5), ^Contents(x , 5 ) 

Receive(a, first[x]), Contents(rest[ x ] , «) 

Stack(«), "^Push( a ,x ,«) , *Contents( y ,5 ) 

=5' Receive ( a ,«) , Contents(cons [ x , y] , 5 ) 

It is often useful to limit the application of rules by constraints, which are implemented as follows. The 
relation called Mf contains the single value true. Hence, an applicative expression that evaluates to a 
Boolean value can be used to constrain rule application. For example: 
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Sched (x.t), Clock (0, if (O t) 
For convenience we often omit the if and write; 



Sched (x^t), Clock (t) , • • • 

We can summarize all that we've seen in the following (simplified) grammar for the Q language: 

Simplified H Grammar 

rule = I cau^e => J effect 

cause = cond , • • * 



cond 




re I args 



args = ( expr , * * * ) 

effect = tra ns ^ * • * 
trans = [-i] rel args 

A complete H grammar can be found in [ MacLennanSS] . 

2.6 Pseudonatural Notation 



We have experimented with several pseudonatural notations for H rules. The notation used in this 
report is a variation of that described in | MacLennan84) and |Ufford85], Relations can be named by 
templates, for example; 



— is stack 

— is contents of — 

— pops — 

— pushes — on — 

— receives — 



Rules are written: 



If — then — 



with or and’ for 



The word ‘given’ represents the cancellation convention Hence the pop 
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rule can be written; 



If 5 is stack, given A pops 5, and given X is contents of 5 
then A receives first of X. and rest of X is contents of 5. 

The push rule is: 

If 5 is stack, given A pushes A' on 5, and given Y is contents of 5 
then A receives 5 and catenation of X and F is contents of S . 

Allowing ‘a’ ‘an’ and ‘the’ as noise words and using words for variable names we have: 

If an object is a stack, given an agent pops the object, and given a list is the contents of the object 
then the agent receives the first of the list, and the rest of the list is the contents of the object. 

If an object is a stack, given an agent pushes a thing on the stack, and 
the stack then the agent receives the stack, and the catenation of the 
tents of the stack. 



given a list is the contents of 
thing and the list is the con- 
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3. Abstract Structure 



For our example programming environment we will use a very simple language of arithmetic expres- 
sions composed of , x, parentheses and literal integers. A typical program is: 

(3^5) X 6 

First we must define an abstract structure for representing programs. There are two kinds of nodes: 

• Constant Nodes: correspond to literals. 

• Application Nodes: correspond to the application of an operator to its operands 
These nodes and their interconnections can be represented by the relations: 

• Con (f;) 

is a constant 

• Litval ( F, E) 

V is the literal_yalue of E, 

• Appl(^) 

is an application. 

• Op(F, 

F is the operator of E. 

. Leh(X,E) 

X is the left_^gument of E. 

. Right ( y, E) 

Y is the right _^gument of E. 

For example, the program 

(3+5) X 6 

would be represented by the database: 
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Appl (nl) 

Op (“X”. nl) 

Left (n2, nl) 

Right (n3, nl) 

Appl (n2) 

Op n2) 

Left (n4, n2) 

Right (n5, n2) 

Con (n3) 

Litval (6, n3) 

Con (n4) 

Litval (3, n4) 

Con (n5) 

Litval (5, n5) 

Meaning (sum, ”) 

Meaning (product, “x”) 

We have given the objects names (‘nl’, ‘n2’, etc.) only so they can be referred to in our example; nor- 
mally they would be anonymous since the tree would have been constructed by an editor. This data- 
base is portrayed in Figure 1. 

In defining the domains of the various relations, it will be convenient to make use of the following 
function abbreviation. Let ‘Function( F, ) ’ mean 

• Degree(F,2), 

• Domain(R ,1,F) , 

• Domain ( Z) ,2, F) , 

• Indexed(F,2) . 

In the pseudo natural notation we can say: 
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is a function from D to means 



has degree 1, R is domedn 1 of F, D is domain 2 of F, and F is indexed on domain 2’. 



Hence, if we know that Function( F,F ) , that is, that F is a function from Z) to F, then we know 
that given any x in D there will be at most one y such that F(t/,r). 

The domains of the abstract program structure relations (in the pseudonatural notation) are as fol- 
lows: 



• ‘constant’ has degree 1. 

• ‘literal value’ is a function from ‘constant’ to ‘integer’. 

• ‘application’ has degree 1. 

• ‘operator’ is a function from ‘application’ to ‘string’. 

• ‘left _argument’ is a function from ‘application’ to ‘expression’. 

• ‘right _argument’ is a function from ‘application’ to ‘expression’. 
In the predicate notation this is: 

Degree (Con, 1) 

Function (litval. Con, integer) 



Degree (Appl, 1) 

Function (Op, Appl, string) 



- 11 - 



Function (Left, expr, expr) 
Function (Right, expr, expr) 



Here we have assumed that 



expr = Con U Appl 
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4. Evaluation 



4.1 Relations 

The preceding relations define the abstract program structure; they are static (with respect to program 
evaluation). We need additional relations to control program evaluation; they are dynamic (with respect 
to program evaluation). The evaluation relations are: 

• Eval {E) 

E is evaluated 

. Value ( V, E) 

V is the value of E 

• Meaning (E, N) 

F is the meaning of N. 

The domains of these relations are: 

• Degree (Eval, l) , Domain(expr, l,Eval). 

‘evaluated’ has degree 1, and ‘expression’ is domain 1 of ‘evaluated’. 

• Function (Value, expr, integer) 

‘value’ is a function from ‘expression’ to ‘integer’. 

Function (Meaning, string, function) 

‘meaning’ is a function from ‘string’ to ‘expression’. 

Eval and Value can be thought of as attributes that at various times are attached to various nodes in the 
tree. In particular, the Eval attribute on a node means that the evaluation of that node has been 
requested, but not serviced. The Value attribute associates a value with a node until such time as that 
value is used. The Meaning relation is a table that maps the names of operators into functions for per- 
forming the operations. 
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4.2 Evaluation of Constant Node 



The transformation required to evaluate a constant node can be portrayed: 




t; 



Con E Value 




That is, if the Eval attribute arrives at a constant node, then we remove the Eval attribute (since the 
request has been serviced), and use a Value link to bind the node’s literal value to the node. In other 
words, when an Eval arrives at a leaf of the tree it is converted into a Value, which wdll travel back up 
the tree. 

The rule for accomplishing this is simply^: 

If given an expression is evaluated, the expression is a constant, a number is the literal value of the 
expression, and a function is the meaning of ‘Tit” 



then the function of the number is the value of the expression. 

This is expressed in the predicate notation as: 

*Eval(E), Con(E), Litval(V,E), Meaning( E,‘Tit”) => Value ( Fj V],E) 

The function that is the meaning of “lit” is the identity function, hence the following simpler rule 
would also work: 

*Eval(F), Con(F), Litval( V,F) ^ Value( V,F) 

We have used the more complicated rule to display the symmetry between the evaluator and the 
unparser (which is discussed in the following section). 



1. The pseudonatural transcription of the rules was prepared by Robert Ufford; see [Ufford85|. 
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4.5 Evaluation of Application Node 



Evaluation of application nodes is accomplished in two steps. First there is a downward analysis pass 
when the Evai attribute reaches the node and is passed to its daughters. Later there is an upward $yn- 
thesis pass when the Values from the daughters arrive back at the node and are used to compute the 
Value for the node. These steps can be visualized as in Figures 2 and 3. 




It is easy to translate these diagrams into rules. First the analysis (downward) rule: 



If given an expression is evaluated, the expression is an application, node _1 is the left _argument of 
the expression, and node_2 is the right _^gument of the expression 

then node is evaluated, and node_2 is evaluated. 

In the predicate notation: 

*Eval(£), Appl(^), Left(A,E), Right( F,E) 

Eval(X), Eval(F) 

Notice that the Eval flag is passed to both daughters simultaneously; thus they can be evaluated con- 
currently or in any other order. Hence, Eval is a parallel evaluator. 

Next we consider the synthesis (upward) rule: 
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If an expression is an application, a string is the operator of the expression, 
ment of the expression, node_2 is the right argument of the expression, a 
of the string, given number _l is the value of node _1 and given number _2 is 
then the function of number and number_2 is the value of the expression 

In the predicate notation: 

Appl(^), Op(^,^;), Left(A,^), Right(r,^), 

Meaning(F,.V), *Value ( L/, A) , *Value( F, Y) 

Value [F \ U,V], E) 

This completes the parallel evaluator for simple abstract arithmetic expressions. 



node _1 is the left argu- 
function is the meaning 
the value of node 2 



- 16 - 



5. Unparsing 



5.1 Relations 

We will now use exactly the same approach as used for evaluation, but for a different purpose — 
unparsing. Instead of computing an inttger value for the abstract program, we will compute a string 
value, which is the program’s concrete representation. That is we will unparse the abstract program. 
This is accomplished by changing the interpretation of the literal constants and the primitive operators. 

This is a quite general approach. From a single program such as the evaluator we can generate a 
family of related programs, just by changing the domain of interpretation of the constants and operators. 
Examples of tools amenable to this approach are unparsers, type checkers, symbolic evaluators. 

The following relations are needed: 

• Unparse (E) 

E is unparsed 
(corresponds to Eval) 

• Image (5, E) 

S is the image of E 
(corresponds to Value) 

• Template ( T, TV) 

T is the template for N 
(corresponds to Meaning) 

Given our previous example, Unparse(nl) will eventually result in 

Image (“( ( 3+5) x6) ”, nl) 

For simplicity we have generated an image that is fully parenthesized. 

The domains of the relations are as follows: 

• Degree (Unparse, I) 

‘unparsed’ has degree 1. 
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• Function (Image, expr. string). 

‘image’ is a function from ‘expression’ to ‘string’. 

• Function (Template, string, function). 

‘template’ is a function from ‘string’ to ‘function’. 

We also will mctke the following assumptions: 

• Assume the function ‘strings int [n]’ converts the integer n into a string. 

• Assume Template (strings— int, “lit”). 

• Assume s "t represents string catenation. 

• For operator symbols N, assume Template (F, N), where 

F\U,V] = “(” ^“)” 

and is “-f ” or or “x” or Thus, if Template (F, “+ ”), then 

F [“3”, “(6 X 2)”] = “(3 + (6 X 2)” 

5.2 Unparsing Constants 

When the Unparse attribute arrives at a constant node, the literal value is converted to a string and 
made the image of the node. In the pseudonatural notation the rule is: 

If given an expression is unparsed, the expression is a constant, a number is the literal value of the 

expression, and a function is the template of “lit” 

then the function of the number is the image of the expression. 

In predicate notation it is: 

*Unparse ( F) , Con(F), Litval( V,E)j Template ( F,F) 

^ Image( F[Kj, F) 

5.3 Unparsing Applications 

The arrival of the unparse attribute at an application node triggers its propagation to the daughter 
nodes. Hence the analysis rule in pseudonatural notation is: 
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If given an expression is unparsed, the expression is an application, node-1 is the left_^gument of 
the expression, and node^ is the right _^gument of the expression 
then node _i is unparsed, and node_2 is unparsed. 

In predicate notation it is: 

*Unparse(^), Appl(i;), Left(A',i;), Right(y,£;), 

=?> Unparse ( A) , Unparse ( y) 

When images arrive at the daughters of the application, they are combined by the template function of 
the operator into an image for the entire node. Hence the synthesis rule in pseudonatural notation is: 

If an expression is an application, a string is the operator of the expression, node _i is the 
left _argument of the expression, node_2 is the right _argument of the expression, a function is the 
template of the string, given image _l is the image of node and given image_2 is the image of 
node_2 

then the function of image _i and image_2 is the image of the expression. 

In the predicate notation: 

Appl(i;), Op(.V,£), Left(X,^), Right(F,£), 

Template (F, TV), *Image( , X) , *Image(T, 7) 

=t> Image (F\U,V\, E) 

This completes the rules for the unparser. 
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6. Information Hicfing 



The relations can be divided into three domains of accessibility on the ba^is of “need to know^’: 




That is, both the evaluator and the unparser need access to the abstract structure relations (read-only 
access, actually). On the other hand, the evaluator needs access to its own d>Tiamic relations, but not 
to those of the unparser. Conversely, the unparser needs access to its own relations, but not the 
evaluator’s. These access restrictions can be enforced by the capability mechanism described in 
[MacLenn aji85] . 
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7. Error Handling 



7.1 Error Detection 

A real programming environment must be able to detect errors and allow the user to deal with them. 
Let’s consider what happens when an error occurs. Suppose we evaluate ((3-r0)"hl). This leads to the 
assertion 

Value (quotient [3,0], n) 

Suppose quotient] 3,0] error. This will trigger that assertion 

Value (sum [error, l], m) 

If we further assume sum [error, l] error, then the value returned for the entire evaluation is 

‘error’. This result is not helpful — it doesn’t tell us where the error occurred, only that an error 
occurred. 

One possible solution is to suppose the primitive operations return “error codes” when something 
goes wrong, that the code indicates what went wrong, and that error codes are distinguishable from 
integers and other “legitimate” values. Then we can incorporate error checking into our interpreter. 
We do this by tentatively attaching the alleged value to the node (via a new relation called Check) until 
it is determined whether or not the value is legitimate. This requires the following additional relations: 

. Check ( V, E) 

V is the value to be checked for E 

• Explanation (5, C) 

S is the explanation of error C 

• Display ( 5) 

S is displayed 

• CurrentNode (E) 

E is the current node 
The domains of these relations are: 
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Function (Check, expr, integer), 

Function (Explanation, errorcode. string). 

Degree (Display, 1). 

Domain (string, 1, Display). 

We then need to modify the second (upward or synthesis) rule for applications. It is replaced by these 
three rules: 

Appl(E), Op(A^,E), Left(X,E), Right ( F,E), 

Meaning(F,.Y), *Value ( f/, A) , *Value( F, Y) 

Check [F [U,V], E). 

*Check( W,E), if (integer! ^ 1 ) ^ ^^lue( W,E). 

*Check( W,E), Explajiation( 5 , PF) , 

*CurrentNode(— ), if (errorcode[ W\) 

=> Display {5 }, CurrentNode(E) . 

The first rule tentatively attaches F[ U , V\ to the application node via Check. If the value of F\ U , V] is 
an integer, then the second rule converts the Check connection to a Value connection to reflect the fact 
that the value is bona fide. On the other hand, if the value of F[U,V] is an error code, then evalua- 
tion is stopped (since no Value is attached to the node), the offending node is recorded (in 
CurrentNode) , and an explanation of the error code is displayed. 

In the pseudonatural notation these rules are: 

If an expression is an application, a string is the operator of the expression, node _1 is the 
left ^argument of the expression, node_2 is the right ^argument of the expression, a function is the 
meaning of the string, given number _1 is the value of node _l, and given number_2 is the value of 
node_2 then the function of number _i and number_2 is the value to be checked for the expression. 

If given an alleged_yalue is the value to be checked for an expression, and the alleged_yalue is an 
integer then the alleged_yalue is the value of the expression. 
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If given an allege d_v'alue is the value to be checked for an expression, the aUeged_value is an 
error __code, a string is the explanation of the error_code, and any_node is the current _node then the 
string is displayed, and the expression is the current _node. 

Thus, if an erro’* value is detected, evaluation is suspended, an error message is issued, and the 
offending node is recorded.- 

The alert reader will realize that with a parallel evaluator there is the possibility of several errors 
occuring concurrently. With the error checking method presented above, all the diagnostics will be 
issued correctly, but CurrentNode will record only the last node to generate an error. A more elaborate 
system would plaee all error nodes in a two plare relation ErrorNodes such that 

ErrorNodes [EjC) 

means that node E generated error code C . It is then necessary to have a command for removing a 
node from ErrorNodes and making it the CurrentNode. The detailed implementation is left as an exer- 
cise for the reader. 

7.2 Susp>ension 

What is the staXe when an error message is sent? There may be parallel computations in progress, but 
since no Value has been provided for E, the evaluation cannot complete. It is suspended, waiting for a 
value for E. 

There are several possible actions: 

1. Supply a value for the offending node and let evaluation continue. E.g.^, 

CurrentNode (E) => Value (0,E); 

2. Unparse the offending node to find the problem: 

CurrentNode (E) => Unparse (E); 

CurrentNode (E), *Image (*S,E) => Display {5}; 

2. We show the rule that would be typed in 0 command mode to effect the desired error recovery action. 
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3. Investigate neighboring nodes (e.g., the divisor): 



*CurrentNode (£'), Right ( Y^E) =?> CurrentNode ( F); 

— un parse as above 

4. Reevaluate the dividend and supply a default value for the divisor. E.g., 

CurrentNode (£), Left [X,E) Eval [X)- 

CurrentNode [E]^ Right [Y^E) =t> Value (1,F); 

5. Abort evaluation by clearing out aU Eval, Value and Check tuples: 

*Eval ^ ; 

*Value ( V,E) ; 

*Check(V,£) => ; 

All these functions (and more) could be provided as commands in a programming environment. In the 
next section we will investigate a command interpreter that permits debugging actions such as these. 
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8. Command Interpreter 



In this section we will describe a simple command interpreter in H rules. This command interpreter 
will permit the interactive evaluation and un parsing of (already entered) abstract programs, in addition 
to various debugging and error recovery activities. 

We assume the existence of a relation called Command that contains the last string or keystroke (we 
don’t care which) typ>ed on the keyboard. We will use boldfaced identifiers such as evaluate to 
represent commands; these identifiers could be bound to strings, key codes, menus coordinates, etc. 

First we consider the evaluate command: its intended effect is to request evaluation of the current 
expression, which might be the entire program or some subexpression of it. This command is imple- 
mented by the following two rules: 

^Command (evaluate), CurrentNode ( J?) =?> Eval (i^), Pendant (E). 

*Pendant (E), *Value {V^E) Display {string*- int [V]}. 

The first rule detects the evaluate command and requests evaluation of the expression. That an evalua- 
tion is in progress is recorded in the Pendant relation. When a value arrives at the pendant node, it is 
displayed by the second rule. 

The auxiliary relation Pendant can be eliminated by using H ’s sequential mechanism: 

^Command (evaluate), CurrentNode (E) 

=> (Eval (E); 

*Value ( V,E) => Display (string*- int [V]} }. 

The commands in the curly braces are evaluated in order. Thus the tuple is asserted to Eval before the 
second rule waits for a tuple in Value. 

The val command is used to explicitly attach a value to a node. This might be used during error 
recovery to allow evaluation to proceed in the face of errors. The command makes use of an additional 
relation Argument which holds a string value typed in from the keyboard. We can imagine this work- 
ing as follows: The user types ‘254’ and strikes the val key. This causes the string “254” to be put *n 
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the Argument relation and the key val to be put in the Command relation. The rule for processing the 
val command is: 

*Command( val) , *Argument( F) , CurrentNode(£') 

Value (int^ string [ V]^E). 

The show command requests the current expression to be unparsed and displayed. It is implemented 
by: 

^Command (show), CurrentNode (E*) 

{ Unparse (E ) ; 

*Image (S,E) => Display {5}}. 

It is also useful to have commands for moving within the abstract program structure. The in command 
‘‘zooms in” by focusing on the left-argument of the current expression: 

^Command (in), *CurrentNode (£*), Left [X,E) 

=5> CurrentNode (A). 

Thus the in command shifts the focus from the current node to the leftr argument of the current node. 

The next command shifts the focus from the left argument of an application to its right argument: 

*Comm 2 Lnd (next), ^CurrentNode (X), Left (X^E), Right ( Y,E) 

CurrentNode ( F) . 

In the pseudonatural notation this is expressed: 

If given next is the command, node is the current^ode, node is the left ^argument of an 
appl _node, and node_2 is the right __^gument of the appl_node then node__2 is the current _node. 

Analogous commands are prev, which shifts from the right argument to the left argument, and out 
which “zooms out” from either the left of right argument to the entire application. 

For debugging it is useful to be able to abort a suspended evaluation. This is accomplished by clear- 
ing out the Eval, Check and Value relations: 
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Command (abort), *Eval (E) => 

else Command (abort), *Check ( V,E) =?> 

else Command (abort), *Value ( V,E] => 

else *Command (abort) => Display {“aborted.”). 

Notice (by the absence of an ‘"^’) that the first three rules leave abort in command; hence they continue 
firing as long as there are tuples in Eval, Check or Value. When there are no more such tuples, the last 
rule cancels the abort command. 

It could be argued that these rules would be more readable if the reassertion of abort were made 
explicit, e.g., 

^Command (abort), *Eval {E) => Command (abort) 
else ^Command (abort), *Check ( V^E) Command (abort) 

else ^Command (abort), *Value ( V,E) =?> Command (abort) 
else ^Command (abort) =;> Display (“aborted.”}. 

This is an unresolved stylistic issue. 

To illustrate the operation of the command interpreter, we present an example session, showing the 

keys typ>ed and the responses of the system. Assume the program ‘((3-^0)^!)’ is already created and 

the current node is the root of the tree. The transcript follows: 

evaluate 
zero divide error 
show 
( 3 - 0 ) 
in 

evaluate 

next 

show 

0 

1 val 
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4 



Notice how the val command triggers completion of evaluation of the program. 
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9. Syntax Directed Edting 



9.1 Incomplete Programs 

In this section we develop a syntax directed editor for this simple lajiguage. Since for editing we need 
to be able to represent incomplete programs we will add a new^ node type, ‘Undef\ representing a part 
of the program that either has not yet been entered or has been deleted: 

txpr = Con U Appl U Undtf 

Next we must modify Eval and Unparse to deal with Undef nodes: 

*Eval(E*), Undef(E'), *CurrentNode(— ) =^> Display!^ ‘Incomplete”}, CurrentNode(E') . 

*Unparse( E') , Undef(E') =?> Image (“< expr> ”, E). 

In other words, evaluating an incomplete program will lead to a diagnostic message and a suspended 
evaluation. Unparsing an incomplete program will show ‘<expr>’ in place of the missing subexpres- 
sion. 

9.2 E<£tor Commands 

What commands do we want? We will want in to “zoom in” on a subexpression: 

A-. 

We will want out to “zoom out” from a subexpression: 




We will want next to shift to the next (to the right) subexpression: 




We will want prev to shift to the previous (to the left) subexpression: 
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It will be convenient to have root to shift to the root of the program tree: 





Furthermore, we w'ill want all of these movement commands to show us the new current expression by 
un parsing it. 

We will also need a begin command to initialize the editing session with an empty tree: 






ii)ncleC 



We will want to be able to delete a node: 



I 



/ 







And we will want to be able to insert a literal value, by ‘n 




Finally we will need the operator commands, -h , — , X, -r, for creating application nodes: 

vi ytje' 4 



These are all simple to implement. 

The predicate form for the in command rule is: 




*Command(in), *CurrentNode( J^) , Left(X,E) 
=> CurrentNode( A) , Comm and ( show) . 



This is the same as the version discussed the previous section, except that we have automatically 
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issued a show command. 



In the pseudonatural notation the in rule is: 

If given “in’’ is the command, given an expression is the current _node, and a node is the 
left __argument of the expression 

then the node is the currentjode, and “show” is the command. 

The out command is analogous, except that there are two rules to handle the two possible paths back to 
the parent: 

*Command(out) , *CurrentNode( vV) , Left(X,£’) 

=t> CurrentNode( £*) , Command(show) . 

*Command(out) , *CurrentNode( F), Right( y,£*) 

=?> CurrentNode( £*) , Command(show) . 

The next and pirev comm ands are similar. 

The delete command is implemented by breaking the current node’s connections with its descen- 
dants and changing its type to Undef. There are three cases depending on whether the node is a con- 
stant, application or already undefined node: 

*Co mm and ( delete) , CurrentNode ( £*) , *Con(£*), *Litval( Fji*) 

==> Undef(£’), Co mm and ( show) . 

*Co mm and (delete), CurrentNode(£’), 

*Appl(i;), *Op(.V,£:), *Leh(X,E), Right( F,£’) 

Undef(£’), Co mm and ( show) . 

*Co mm and (delete), CurrentNode(£’) , Undef(£’) 

=?> Display{“aJready deleted”}. 

Note that subtrees are not disassembled; hence they could be reused (say by a move command). 

There are two rules to implement the ^ command. The first one is to create a constant node with a 
given literal value: 
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*Command(“f^”) , *Argument( F), if ( integer( V^) ) , Curren tNode ( £*) . *Undef(£') 

Con(£'), Litval( F,£’) , Comm and (show) . 

The other rule handles the case where the current node is already defined; we require a node to be 
deleted before it can be replaced: 

*Command(“^”) , ’^Argument( F), CurrentNode ( £*) , -^Undef(£') 

==> Display {“defined node”}. 

Next we consider that commands for creating application nodes. If the user types ‘-h ’ then we must 
create an Appl node with two undefined daughters and a ’ for the operator: 

*Command(“+ *CurrentNode ( ^) , *Undef(^), *Avail(A:, F) 

Appl(^), Op(“-f”,i;), Left(X,E), Right(F,^;), 

Undef(X), Undef( F), CurrentNode ( X) . 

Here we have assumed that Avail contains an indefinite supply of unused objects; objects are allocated 
by a system procedure in the McArthur interpreter. Also notice that the focus is automatically shifted 
to the left argument of the new application. 

It would be somewhat inconvenient to repeat the above rule for each of the four operators. Also we 
would need four rules for detecting already defined nodes. Fortunately we can use the applicative 
features of 0 to make one rule handle all four operators: 

*Command(/), member [/, [‘‘H- ”, *‘x”, 

*CurrentNode( £■) , *Undef(£'), *Avail(X, F) 

Appl(^), 0p(/,£’), Left(X,£’), Right( Y,E), Undef(X), Undef( F), CurrentNode( X) . 

Already defined nodes are handled by: 

*Command(/), member [/,[“+ ”, “x”, CurrentNode ( £*) , -Undef(£') 

=^> Display{“ defined node”}. 

The begin command is implemented by creating a tree containing a single undefined node: 
*Commajid(begin) , *CurrentNode (— ), ^Avai^E*) Root(^), Undef(£ . 
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The root command is simple since the Root relation holds the root of the tree (set by the begin 



command) : 

*Command(root) , *CurrentNode (— ), Root(£') 

=> CurrentNode(£') , Command(show) . 

A typical session will illustrate operation of the syntax directed editor, 
program ‘(3-r0)^l^ and change it to ‘(3^1)^!’. We show commands 
indented: 

begin 
< expr> 



3 # 

next 

< expr> 

0 # 

out 

( 3 - 0 ) 

out 

( ( 3-rO) 4- < expr> ) 

in 

( 3 - 0 ) 

next 

< expr> 

1 # 



Our goal will be to construct the 
on the left margin, and responses 
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root 



((3-0) + l) 
evaluate 
zero divide error 
show 
(3-0) 
in 

3 

next 

0 

delete 
1 # 
root 

((3-l) + l) 
abort 
aborted, 
evaluate 

4 

This is, of course, a very simple system for a very simple language. But it illustrates the ideas of a pro- 
gramming environment. A version of this system that executes correctly under the McArthur inter- 
preter [McArthur84] is shown in the appendices. 

9.3 Permissions 

We review the access to the various relations needed by the various tools: 

• Editor — can read and update program structure relations (Con, Litval, etc.), CurrentNode, Root 
and evaluator and unparser relations (Eval, Check, Value, Unparse, Image). 

• Evaluator — can only read program structure relations; can read and update evaluation relations 
(Eval, Check and Value); can update CurrentNode and Display; can read Meaning and Explanation. 



- 34 - 



# Unparser — can only read program structure relations; can read and update unparser relations 
(Unparse and Image); can read Template. 

These rights can be enforced using the Q capability mechanism; see MacLennan83 j or j MacLennanSS] 
for a description. 

10. Conclusions 

We believe that this report has shown that major components of a programming environment, albeit in 
a rudimentary form, can be conveniently programmed in Q . If this experience is typical, if a reason- 
able programming environment can be prototyped in a few hundred rules, then we believe that our 
ability to prototype software will have been much enhanced. Succeeding reports in this series will 
further investigate this hypothesis by expanding the capabilities of the prototype programming environ- 
ment. 
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APPENDIX A: Prototype Programming Environment 
Predicate Notation for 0 

The following is a loadable input file for the prototype programming environment described in this 
report. It is accepted by the McArthur interpreter [McArthur84 j , which differs in a few details from 
the n described in this report (see | MacLennan84] ) . A transcript of a test execution of this environ- 
ment is shown in Appendix C. 

! PI-1 

! Rules and associated definitions for 

! an arithmetic expression language. 

! Relations 

! Program Structure Relations 

define {root, ”Appl”, newrel{}}; 
define (root, **Op", newrel{}}; 
define (root, ’Teft”, newrel{}}; 
define (root, ’Tlight”, newrel{}}; 
define (root, ’’Con", newrel{}}; 
define {root, ’Titval", newrel{}}; 

! Evaluation Relations 

define {root, ’TEval", newrel{}}; 
define {root, ”Check”, newrel{}}; 
define {root, ’^alue”, newrel{}}; 
define {root, "Meaning", newrel{}}; 
define {root, ’Explanation", newrel{}}; 

! Unparser Relations 
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define {root, '^'nparse", newrel{)}; 
define {root, "Image". newrel{}}; 
define {root, ’Template", newrel{}); 

! Command Interpreter Relations 

define {root, "Command", newrel{}}; 
define (root, "Argument", newrel{}}; 
define {root, "Root", newrel{}}; 
define {root, "Undef", newrel{}}; 
define {root, ’CurrentNode", newrel{}}; 

define {root, "EvalPending", newrel{}}; 
define {root, "ShowPending", newrel{}}; 
define {root, "Create A ppl", newrel{}}; 
define {root, "CreateRoot", newrel{}}; 
define {root, ’Script", newrel{)}; 
define {root, ’PendScript", newrel{}}. 

! Functions 

fn Id [xj : x; 
fn Sum [x,y] : x + y; 
fn Dif [x,y): x - y; 
fn Product |x,y]: x * y; 
fn Quotient [x,y]: 

if y = 0 -> [ "error", !]■ 
else X / y; 



fn IsErrorcode [w]: 



if "IsListfw) I w = Nil -> Nil 
else first! w] = ”error^^; 

fn upSum jx,yl: 

fn upDif IX, yi: ^ x ^ - y - 

fn upProd :x,yh "("+ x + " x -r y 
fn upQuot jx,yj: x '^ / ^' + y -r 

! Built-in Tables 

Meaning (Sum, 

Meaning (Dif, 

Meaning (Product, "x^’); 

Meaning (Quotient, ; 

Meaning (Id, 'lit”); 

Template (upSum, ”-4* ”) ; 

Template (upDif, 

Template (upProd, ”x”); 

Template (upQuot, ”/”); 

Template (int_str, "lit”); 

Explanation ('Incomplete program”, ["error”. 
Explanation ('division by zero”, ["error”, ij). 

! the Rules 

definefroot,. "PIlRules”, 

< < 

! Evaluator Rules 



! Constant nodes 



if *Eval(e), Con(e), Litval(v,e). Meajiing(f, ’’lit") 

-> Value(f[ Vj . e) ; 

! Appl nodes 

if *Eval(e), Appl(e), Left(x,e), Right(y,e) 

-> Eval(x), Eval(y); 

if *Value(u,x), *Value(v,y), Appl(e), Op(n,e), Left(x.e), Right(y,e), Meaning(f, n) 
-> Check (f[u,vj , e) ; 

! Error Checking 

if *Check(w, e), ‘IsErrorcode [ w] 

-> Value(w, e) ; 

if *Check(w, e), IsErrorcode| w] , Explanation( s, w), *CurrentNode( q) 

-> displayn{s}, CurrentNode(e) ; 

! Un parser 

! Constant Nodes 

if *Unparse(e) , Con(e), Litval(v,e), Template(f, "lit") 

-> lmage(f[v] , e); 

! Identifier nodes 

! Appl nodes 

if *Unparse(e) , Appl(e), Left(x,e), Right(y,e) 

-> Unparse (x) , Unparse (y); 

if *Image(u,x) , *Image(v,y), Appl(e), Op(n,e), Left(x,e), Right(y,e), Template(f, n) 
-> Image(flu,v], e); 
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! Command Interpreter Rules 



! evaluate Command 

if *Comm and ( "evaluate") , CurrentNode(E) 

-> Eval(E) , EvalPending(E) ; 

if *Value ( V,E) , *EvalPending(E) 

-> displayn {V}; 

! return Command 

if *Command(’Val"), *Argument( V) , CurrentNode (E) 

-> Value (V,E); 

! show Command 

if *Command( ’^how") , CurrentNode(E) 

-> Unparse(E), ShowPending(E) ; 

if *lmage(S,E), *ShowPendin g(E) 

-> displayn {S}; 

1 abort Command 

if Command( "abort") , *Eval(E) -> ; 
if Command( "abort"), *Value(V,E) -> ; 
if Command( "abort") , *Check(V,E) -> ; 

if *Co mm and ("abort"), *E)val(E), "VaJue(V,E) -> displayn {"aborted"}; 
! Handle incomplete program 
if *Eval(E), Undef(E), *CurrentNode(Q) 
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-> dispiayn ( ^Incomplete , CurrentNode (E) ; 



if *Unparse(E), Undef(E) 

-> Image ( "< expr> ”, E); 

! Syntax Directed Editing 

! in Command 

if *Command('^n”) , *CurrentNode(E), Left(X,E) 

-> CurrentNode(X) , Command( ”show”) ; 

if *Command( "out”) , *CurrentNode (X) , Left(X,E) 

-> CurrentNode(E), Com mand( "show") ; 

if *Command( "out’^ , *CurrentNode( Y) , Right(Y,E) 

-> CurrentNode(E) j Comm and ( *!show") ; 

! next Command 

if *Comm and ( "next") , ^CurrentNode (X) , Left(X,E), Right(Y,E) 

-> CurrentNode( Y) , Com m and ( "show”) ; 

! prev Command 

if *Command("prev"), *CurrentNode( Y) , Right(Y,E), Left(X,E) 

-> CurrentNode(X) , Com mand( "show") ; 

! delete command 

if *Comm and ( "delete") , CurrentNode (E) , *Con(E), *Litval(V,E) 

-> Undef(E), Com mand( "show") ; 

if *Command(’Vielete"), CurrentNode(E) , *Appl(E), *Op(N,E), *Left(X,E), Right(Y,E) 
-> Undef(E), Comm and ("show"); 
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if "^Command( "delete”) , CurrentNode ( E) , Undef(E) 

-> displayn ("already deleted") ; 

! # Command 

if *Command("#"), *Argument( V) , IsIntjVj, CurrentNode(E) , *Undef(E) 

-> Con(E )5 Litval(VjE), Command( ’*show") ; 

if *Command("^"), *Argument( V) , CurrentNode(E) , “Undef(E) 

-> displayn ("de 6 ned node"); 

! -h , X , / Commands 

if *Command(op) , member [op, [ "-f ", ’!x" "/"]j, "^CurrentNode ( E) , *Undef(E) 

-> Create Appl(op, E, newobj{}, newobjQ); 

if "^Create Appl(op,E,X,Y) 

.> Appl(E), Op(op,E), Left(X,E), Right(Y,E), Undef(X), Undef(Y), CurrentNode(X) ; 

if *Command(op) , member [op, ["-I- ", ’be", "/"]), CurrentNode (E) , TJndef(E) 

-> displayn ("defined node") ; 

! begin Command 

if *Command( ’^egin") , ^CurrentNode(Q) 

-> CreateRoot(newobj{}) ; 

if *CreateRoot( E) 

-> Root(E), Undef(E), CurrentNode(E); 

! root Command 

if *C )mmand( "root") , *CurrentNode( Q), Root(E) 

-> CurrentNode (E), Command( '^how") ; 
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! Test Driver 



if *Script(Nil) -> displayn{'*Script completed"} 

else if *Script(L), (first[L]= I first' 'Val") 

-> { displayn + first [rest | L] ] -t- first [L]}; 

Command(first[L) ) , Argument(first[rest| L) ) ) , PendScript(rest[rest[L) ] ) } 

else if *Script(L) 

-> { displayn {" ... " + first [L] }; 

Command(first[L) ) , PendScript(rest[L) ) }; 

if *PendScript( L) , "Command(Q) -> Script(L) 

>> }• 

define {root, "testscript", 

I'lDegin", "-f ", "/", 3, •'next", 0, "out", "out", 

’^n", ’^ext", 1, "root", "evaluate", *!show", 'in", 

"next", "delete", 1, "root", "abort", "evaluate"] }. 

! activate the rules 

act{ PIlRules }. 

CurrentNode(Nil) . 
displayn{'PI-l System loaded"). 



APPENDIX B: Prototype Programming Environment 
Pseudo natural Notation for 0 

This appendix displays the prototype programming environment of Appendix A in the pseudonatural 
notation designed by Robert Ufford [Ufford85]. Ufford also performed this translation of the Appendix 
A program into the pseudo natural notation. 

! 

PM 

Rules and associated definitions for 
an arithmetic expression language. 

I 

! Relations ! 

! Program structure relations ! 

"Application" (procedure) is defined as a relation. 

*KDperator" (procedure) is defined as a relation. 

'Left _^gument" (procedure) is defined as a relation. 

'Right ^argument" (procedure) is defined as a relation. 

"Constant" (procedure) is defined as a relation. 

'Literal_yalue" (procedure) is defined as a relation. 

! Evaluation relations ! 

'Evaluated" (procedure) is defined as a relation. 

'Checked" (procedure) is defined as a relation. 

'^alue" (procedure) is defined as a relation. 

"Meaning" (procedure) is defined as a relation. 

'Explanation" (procedure) is defined as a relation. 
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! Unparser relations ! 



'Unparsed’' (procedure) is defined as a relation. 

'Image" (procedure) is defined as a relation. 

'Template" (procedure) is defined as a relation. 

! Command interpreter relations ! 

"Command" (procedure) is defined as a relation. 
"Argument" (procedure) is defined as a relation. 
"Root^ode" (procedure) is defined as a relation. 
'Undefined" (procedure) is defined as a relation. 

"Current _node" (procedure) is defined as a relation. 

'Pending_evaluation " (procedure) is defined as a relation. 
'Shown" (procedure) is defined as a relation. 

'New _application" (procedure) is defined as a relation. 
"New^oot" (procedure) is defined as a relation. 

'Script" (procedure) is defined as a relation. 
'Pending__script" (procedure) is defined as a relation. 

! Functions ! 
function identity [x]: x. 
function sum [x,y): x -f y. 
function difference [x,y]: x - y. 
function product [x,y]: x * y. 
function quotient [x,y]: 

if y = 0 then the J[ist of the "error_code" and 1 
else X / y. 

function error_code [W]: 
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if W (predicate) is not a_list W = Nil then Nil 
else the first (function) of W = ”error_code 

function sum_template [x,yj: ”( ’’ ^ ^ ^ Y + ") "• 

function diffe re nce_tem plate [x,y|: "(” — x ^ ^ y ^ '»)»> 

function product_tem plate |x,yj: ”(" + x -r " x ” — y ^ ”) ’’. 
function quo tie nt_tem plate [x,yj: "(’’-i- x ^ y + ") ". 

! Built-in tables ! 

Sum is the meaning of 'V 
Difference is the meaning of 
Product is the meaning of '*x". 

Quotient is the meaning of 
Identity is the meaning of 'lit". 

Sum_template is a template for "-r 
Difference_template is a template for 
Product_tem plate is a template for 'be". 

Quo tie nt_tem plate is a template for "/". 

String^otation is a template for "lit". 

"Incomplete program" is an explanation for the_list of error_code and 0. 
'Division by zero" is an explanation for the_l_ist of error_code and 1. 

! Noise words ! 

"Must" (procedure) is defined as a noise_yerb. 

’De" (procedure) is defined as a noise_yerb. 

'Deing" (procedure) is defined as a noise_yerb. 

"Established" (procedure) is defined as a noise_yerb. 

'Will" (procedure) is defined as a noise_yerb. 
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"Another" (procedure) is defined as a noise_prep. 



! The rules ! 

’PIlj[ules" (procedure) are defined as 

Rules 

! Evaluator rules ! 

! Constant nodes ! 

If given an expression is being evaluated, 
the expression is a constant, 

a number is the literal_yalue of the expression, and 
a lit_function is the meaning of "lit" 

then the lit^unction (function) of the number is the value of the expression 

! Application nodes ! 

If given an expression is being evaluated, 
the expression is an application, 
nodel is the left _argument of the expression, and 
node2 is the right argument of the expression 

then nodel must be evaluated, and 
node2 must be evaluated; 

If given value 1 is the value of nodel, 
given value2 is the value of node2, 
the expression is an application, 
a string is the operator of the expression, 
nodel is the left _^gument of the expression, 
node2 is the right _argument of the expression, and 
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an operator_function is the meaning of the string 
then the operator_function (function) of value! and value2 must be checked 
for the expression; 

1 Error checking ! 

If given an alleged_yalue is being checked for an expression, and 
the alleged_v’alue (predicate) is not an error_code 
then the alleged_yalue is the value of the expression; 

If given an alleged_yalue is being checked for an expression, 
the alleged_yalue (predicate) is the error_code, 
a string is an explanation for the allege d_v alue , and 
given any_node is the current_node 
then the string (procedure) is displayed_with_return and 
the expression is the current_node; 

! Un parser ! 

! Constant Nodes ! 

If given an expression is being unparsed, 
the expression is a constant, 

value 1 is the literal_yalue of the expression, and 
a lit^function is a template for ’lit” 

then the lit_function (function) of valuel is the image of the expression; 

! Identifier nodes ! 

! Application nodes ! 

If given an expression is being unparsed, 
the expression is an application. 
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nodel is the left _argument of the expression, and 
node2 is the right _argument of the expression 
then nodel must be unparsed and 
node2 must be unparsed; 

If given image 1 is the image of nodel, 
given image2 is the image of node2, 
the expression is an application, 
a string is the operator of the expression, 
nodel is the left _argument of the expression, 
node2 is the right _argument of the expression, and 
an operator_f unction is a template for the string 
then the operator^unction (function) of imagel and image2 
is the image of the expression; 

! Command interpreter rules ! 

! Evaluate command ! 

If given ’’evaluate” is the command, and 
an expression is the current^ode 
then the expression must be evaluated, and 
the expression is pending_evaluation; 

If given value 1 is the value of an expression, and 
the expression is pending_evaluation 
then value 1 (procedure) is displayed_with_return; 

! Return command ! 

If given ”val” is the command, 

given value 1 is the argument, and 
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an expression is the current^ode 
then value 1 is the value of the expression; 

! Show command ! 

If given ’^how” is the command, and 
an expression is the current^node 
then the expression must be unparsed, and 
the expression will be shown; 

If given a string is the image of an expression, and 
given the expression must be shown 
then the string (procedure) is displayed_with^eturn; 

! Abort command ! 

If ’’abort*’ is the command, and 

given an expression is being evaluated 
then Ido nothing! . 

If ’’abort” is the command, and 

given a_yalue is the value of an expression 
then Ido nothing! . 

If ’’abort** is the command, and 

given a_yalue is being checked for an expression 
then Ido nothing! . 

If given ’’abort” is the command, 

an expression is not being evaluated, and 
a_yalue is not the value of the expression 
then ’’aborted” (procedure ) is displayed_with^eturn; 
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! Handle incomplete program ! 

If given an expression is being evaluated, 
the expression is undefined, and 
given any_node is the current_node 
then ’Incomplete” (procedure) is displayed_with^eturn, and 
the expression is the current__node; 

If given an expression is being unparsed, and 
the expression is undefined 
then ”< expr> "is the image of the expression; 

! Syntax Directed Editing ! 

! in Command ! 

If given ’^n" is the command, 

given an expression is the current _node, and 
nodel is the left _argument of the expression 
then nodel is the current_node , and 
’^how" is the command; 

If given ’but" is the command, 

given nodel is the current_node, and 
nodel is the left __argument of an expression 
then the expression is the current _node, and 
’^how"is the command; 

If given ’but" is the command, 

given node2 is the current_node, and 
node2 is the right _^gument of an expression 
then the expression is the current^node, and 



- 51 - 



’%how" is the command; 



! next Command ! 

If given ’*next” is the command, 
given nodel is the current _nodej 
nodel is the left _argument of an expression, and 
node2 is the right _argument of the expression 
then node2 is the current jnode, and 
*^how*'is the command; 

! prev Command ! 

If given ’*prev" is the command, 
given node2 is the current _node, 
node2 is the right _argument of an expression, and 
nodel is the left ^argument of the expression 
then nodel is the current _node, and 
''show" is the command; 

! delete command ! 

If given "delete" is the command, 
an expression is the current^ode, 
given the expression is a constant, and 
given a_yalue is the literal_yalue of the expression 
then the expression is undefined, and 
'^how"is the commajid; 

If given 'delete" is the command, 
an expression is the current _node, 
given the expression is an application, 
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given a string is the operator of the expression, 
given nodel is the left _^gument of the expression, and 
node2 is the right _argument of the expression 
then the expression is undefined, and 
'^how" is the command; 

If give ’’delete” is the command, 

an expression is the current jnode, and 
the expression is undefined 

then "already deleted" (procedure) is displayed_with_return 

! Command ! 

If given is the command, 

given value 1 is the argument, 
value 1 (predicate) is an^nteger, 
an expression is the current^ode, and 
given the expression is undefined 
then the expression is a constant, 

value 1 is the literal_yalue of the expression, and 
’^how" is the command; 

If given is the command, 

given value 1 is the argument, 
an expression is the current _node, and 
the expression is not undefined 
then "defined node" (procedure) is displayed_with^eturn; 

! -h , x, / Commands 

If given a strmg is the command. 
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the string is a member of the_list of 'V ”, '*x”, and 

given an expression is the current _node, and 
given the expression is undefined 

then the expression is established as anew _application with a string 
and an object and another object; 

If given an expression is a new _application with a string and nodel 
and node2 

then the expression is an application, 

the string is the operator of the expression, 
nodel is the left _argument of the expression, 
node2 is the right _argument of the expression, 
nodel is undefined, 
node2 is undefined, and 
nodel is the current _node; 

If given a string is the command, 

the string is a member of the_list of ”, *bc”, and "/”, 

an expression is the current ^ode, and 
the expression is not undefined 

then ’’defined node” (procedure) is displayed_with^eturn; 

! begin Command ! 

If given "begin” is the command, and 
given any_node is the current _node 

then an object is established as a new_root; 

K given an expression is a new^root 

then the expression is arootjode, 
the expression is undefined, and 
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the expression is the current^ode; 

! root Command ! 

If given ’Voot” is the command, 

given any_node is the currentjode, and 
an expression is the root^ode 

then the expression is the current^ode, and 
'bhow" is the command; 

! Test driver ! 

K given Nil is the script 

then 'Script completed" ( procedure) is displayed_with^eturn 

Else if given a list is the script, and 
(the first (function) of the list = 

the first (function) of the list = 'Val") 

then 

begin 

" ... " (procedure) is displayed; 

the first (function) of the rest (function) of the list 
(procedure) is displayed; 

the first (function) of the list (procedure) is 
displayed_with_j;eturn; 

the first (function) of the list is the command, 

the first (function) of the rest (function) of the list is the argument, and 

the rest (function) of the rest (function) of the list is the pendin g_script 
end^block; 

Else if given a list is the script 
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then 



begin 

" ... ” (procedure) is displayed; 
the first (function) of the list (procedure) is 
displayed_^dth^eturn; 

the first (function) of the list is the command, and 
the rest (function) of the list is the pending_script 
end_block; 

If given a list is the pending_script, and 
something is not the command 
then the list is the script; 

end_rules. 

! activate the rules ! 

The PIl_rules (procedure) are activated. 

Nil is the current _node. 

'Pl-l System loaded” (procedure ) is displayed_with_return. 
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APPENDIX C: Transcript of H Session 



The following is a transcript of an H session illustrating the operation of the prototype programming 
environment showm in Appendix A. The assertion ‘Script ( testscript) ’ causes the commands in 
testscript to be executed in order. Each command is printed on a separate line, followed by w^hatever 
output is generated by the programming environment. This trajiscript was produced by the McArthur 
interpreter [McArthur84j. 

OMEGA-1 11/30/84 

Use Cntl-D or exit{} to quit. 

For help, enter help{’7”}- 

To report a bug, enter Bugs{}. 

PI-1 System loaded 
> Script (testscript) . 

(begin, +,/,#, 3, next, 0, out, out, in, next, 1, root, evaluate, show, in, in, next, 
delete, 1, root, abort, evaluate] 

... begin 

... + 

... 3# 

3 

... next 
< expr> 

... Utt 
0 

... out 
(3/0) 

... out 
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( (3 / 0) + < expr> ) 
... in 
(3/0) 

... next 

< expr> 

... 1# 

1 

... root 

((3/0) + 1) 

... evaluate 
division by zero 
... show 
(3/0) 

... in 

3 

... next 
0 

... delete 

< expr> 

... 1# 

1 

... root 

((3/1) + 1) 

... abort 
aborted 
... evaluate 

4 

Script completed 
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i 






> exit{}. 
Goodbye. 







''t'v: 















5 - 
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